REMARKS 

Claims 1-32 remain pending in the application. Reconsideration is respectfully 
requested in light of the following remarks. 

Provisional Double Patenting Rejection : 

The Examiner rejected claims 1-32 under the judiciary created doctrine of double 
patenting as being unpatentable over claims 1-38 of co-pending Application No. 
10/090,893. In the event that the instant Application or the co-pending Application 
issues, Applicants will present arguments or file a terminal disclaimer to obviate the 
double patenting rejection over claims 1-32. 

Section 103(a) Rejection : 

The Examiner rejected claims 1-32 under 35 U.S.C. § 102(e) as anticipated by or, 
in the alternative, under 35 U.S.C. § 103(a) as obvious over Mansour et al. (U.S. 
Publication 2002/0129096) (hereinafter "Mansour"). Applicants respectfully traverse 
this rejection for at least the following reasons. 

Regarding claim 1, contrary to the Examiner's assertion, Mansour fails to teach or 
suggest a server... configured to generate a small device document in a small device 
format from a document in a server format. The Examiner cites paragraphs [0022] - 
[0024] and paragraph [0055] as disclosing this limitation. However, these paragraphs do 
not describe a server generating such a document. Instead, they describe a method for 
displaying application data on a client device: "the distributed architecture transmits only 
data and a brief description of how to display it... between the server and client. The 
client side software, using the native GUI controls, produces the UI elements on the 
client...". Nothing in this citation discloses that the server generates a document in a 
small device format from a document in a server format, as recited in claim 1 . In fact, 
these paragraphs include a description that application data and UI (user interface) 
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information are separated in Mansour's architecture, and that the server provides a UI 
form definition to the client device, which renders the UI according to the form. Since 
the application data and its display format information are separated on the server and 
only combined for display on the client device, Mansour actually teaches away from a 
server generating a document in a small device format, as recited in claim 1 . 

Further regarding claim 1, contrary to the Examiner's assertion, Mansour fails to 
teach or suggest that, to generate a small device document in a small device format from 
a document in a server format, the server is further configured to exclude one or more 
formats for content of the document in the server format from the small device document. 
The Examiner cites paragraph [0118] "server versions" as disclosing this limitation. This 
paragraph states that, "the client application 728 is preferably designed to be compatible 
with any number of UI server versions ." Paragraph [0118] also states, "the client 
application 728 (along with the communication interface element 730 and the OS* 
dependent code 732) is embedded in read-only memory in the client device." Thus, this 
passage describes how a static client application interacts with different UI modules. 
Clearly this has absolutely nothing to do with documents in small device formats, much 
less with generating a small device document in a small device format * or with excluding 
one or more formats for content of the document in the server format from the small 
device document , as recited in claim 1 . 

Mansour also fails to teach or suggest that the server is further configured to 
provide the small device document to a small device coupled to the server, contrary to the 
Examiner's assertion. The Examiner cites paragraph [0053] "suitably configured" as 
disclosing this limitation. However, this citation states only, "System 100 is suitably 
configured to deliver information, data, control commands, and the like, from at least one 
server device (or system) to any number of remote end user client devices." It does not 
describe that any of these items is a small device document in a small device format, nor 
that any of these items is generated by the server in the manner recited in claim 1. k In 
addition, Mansour teaches away from this limitation in paragraph [0073] which 
describes, "opening large messages or attachments is much simpler because the 
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attachment is actually being opened on the UI server , and only a single page view (and 
possibly some additional cached data) need be transmitted to the client at any one time", 
and in paragraph [0076] , which states, "With the distributed UI system, the client device 
only displays and stores a relatively small amount of data , and more data is downloaded 
from the UI server as the user scrolls down to view it." Thus, Mansour clearly does not 
teach or suggest providing the small device document to a small device, as recited in 
claim 1. 

Further regarding claim 1, Mansour fails to teach or suggest the small device... is 
configured to modify the small device document to produce a modified version of the 
small device document. The Examiner's citation (paragraph [0185] "updated version") 
refers to "a process for handling data modifications, where such modifications originate 
at the data source" in which "the UI server may test whether the modified data is 
associated with a data item that is already cached at the client (query task 1708). For 
example, the modified data may be an updated version of a cached data item. In this 
regard, the UI server may poll its shadow cache to determine the current status of the 
client cache. If the modified data item is not cached at the client, then data modification 
process 1700 exits (this modified data item will be maintained by the UI server until the 
client device calls the respective application or until the data item is modified again)." 
This paragraph describes that once an "updated version" of a cached application data 
item is produced by an external source, the server decides whether to "push" the data 
item to the client or to wait until later to transmit the .modified data item. This has 
absolutely nothing to do with a small device being configured to modify the small device 
document (which was generated by the server) to produce a modified version of the 
document, as recited in claim 1. 

Finally, Mansour fails to teach or suggest the server is further configured to 
generate a modified version of the document in the server format from the modified 
version of the small device document, wherein, to generate a modified version of the 
document in the server format from the modified version of the small device document, 
the server is further configured to restore the one or more formats for content of the 
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document in the server format excluded from the small device document, as the Examiner 
submits. The Examiner cites paragraph [0185] "updated version", paragraph [0217] "the 
UI server are configured to process and manipulate to perform different UI form for the 
client device" and paragraphs [0053-0218] "suitably configured" as disclosing these 
limitations. However, the "updated version" of paragraph [0185] refers to an application 
data item that may be "pushed" to a client. Paragraph [0217] describes UI server 2404 
performing UI formatting 2416 to format and configure different UI form definitions 
2418 for use by the client device 2402. These UI form definitions 2418 are not modified 
or unmodified documents in a server or small device format. Instead, they are definitions 
of display formats themselves. See, e.g., paragraph [0068] in which UI forms are 
defined: 

As used herein, a "UI form" is a description of the layout of the client 
device display at any given moment. A UI form definition specifies a list of 
controls, the respective locations of the controls as rendered on the client device 
display screen, event scripts, data sources, and possibly other characteristics. A UI 
form preferably does not include the user's data that is to be displayed by the UI 
controls, but it may specify where a given control can retrieve source data items 
(e.g., a pointer to a memory location at the client device), and/or which event 
scripts are executed in response to the activation of certain controls. 

Thus, the Examiner's citations clearly have nothing to do with a modified version 
of a document in either a small device format or a server format , much less with 
generating a modified version of a document in server format from a modified version of 
a small device document in small device format. There is also* nothing in Mansour to 
teach or suggest restoring one or more formats for content , as recited in claim 1. 

The Examiner submits that it was clear "that the UI server could manipulate the 
configured process by a suitable configured or restored the format in the server format 
excluded from the client document. Doing so would provide the flexibility to combine 
and merge the documents between the server- client formats by using any network 
device." Applicants disagree. First, as discussed above, there is nothing in Mansour to 
teach or suggest the server generating a small device document in small device format 
and excluding one or more formats for content. Therefore, there would be no need to 
restore any such excluded formats. Second, the Examiner's suggestion to "combine and 
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merge the documents between the server- client formats" teaches away from the system 
of Mansour, in which application data and display formats are maintained separately by 
the server and only application data and some information about how to display it (e.g., 
UI forms or commands) are transmitted between server and client. Finally, there is 
nothing in the cited art that provides a motivation to change this principle of the operation 
in order to "provide flexibility", as the Examiner suggests. As stated in the MPEP 
§2143.01 "If the proposed modification or combination of the prior art would change the 
principle of operation of the prior art invention being modified, then the teachings of the 
references are not sufficient to render the claims prima facie obvious . In re Ratti , 270 
F.2d 810, 123 USPQ 349 (CCPA 1959). . ." {emphasis added). 

Applicants also remind the Examiner that to establish a prima facie obviousness 
of a claimed invention, all claim limitations must be taught or suggested by the prior art. 
In re Royka, 490 F.2d 981, 180 U.S.P.Q. 580 (C.C.P.A. 1974), MPEP 2143.03. As 
discussed in detail above, Mansour fails to teach or suggest many of the limitations of 
Applicants' claim 1 . 

For at least the reasons above, the rejection of claim 1 is not supported by the 
cited art and removal thereof is respectfully requested. Similar remarks apply also to 
independent claims 10, 19 and 27, which recite limitations similar to those in claim 1. 

Regarding claim 2, contrary to the Examiner's assertion, Mansour fails to teach or 
suggest in paragraph [0118] the document in the server format is an office productivity 
document. As discussed above, this paragraph refers to client application 728 and has 
nothing to do with documents in server formats, much less office productivity documents. 
Furthermore, there is nothing in Mansour to teach or suggest a server generating an office 
productivity document in a small device format from an office productivity document in 
a server format, as recited in Applicants' claims. 

For at least the reasons above, the rejection of claim 2 is not supported by the 
cited art and removal thereof is respectfully requested. 
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Regarding claim 3, Mansour fails to teach or suggest wherein, to restore the one 
or more formats for content of the document in the server format excluded from the small 
device document, the server is further configured to compare modified content of the 
modified version of the small device document to corresponding content of the document 
in the server format to determine one or more formats for the modified content of the 
modified version of the small device document to be merged with the document in the 
server format. Mansour also fails to teach or suggest the server is configured to merge 
the modified content of the modified version of the small device document into the 
document in the server format in accordance with the determined one or more formats 
for the modified content. 

The Examiner's citations [Mansour, modified version, col. 6 lines 35-42; a 
comparison, col. 10 lines 3-17] and [Mansour, merge email, col 2 lines 49-67] appear to 
be artifacts of the previous Office Action, in which the Examiner cites the Mendez 
reference at these locations. No discussion of the limitations of claim 3 are found in 
these locations in Mansour. Therefore, the Examiner has not even attempted to establish 
a case of prima facie obviousness for claim 3 in the present Office Action. 

Furthermore, as discussed above regarding claim 1, Mansour fails to teach or 
suggest generating a small device document and excluding one or more formats for 
content. Therefore, Mansour would have no reason to restore such formats at all, much 
less in the specific manner recited in claim 3, and does not teach such restoration. 

For at least the reasons above, the rejection of claim 3 is not supported by the 
cited art and removal thereof is respectfully requested. 

Regarding claim 4, contrary to the Examiner's assertion, Mansour fails to teach or 
suggest wherein, to generate a modified version of the document in the server format 
from the modified version of the small device document, the server is further configured 
to determine differences between the modified version of the small device document and 
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the document in the server format, wherein each determined difference indicates changed 
content of the modified version of the small device document; and for each of the 
determined differences, merge corresponding changed content of the modified version of 
the small device document with the document in the server format. The Examiner cites 
paragraph [0118] "server versions" as disclosing these limitations. However, as 
discussed above, paragraph [0118] refers to a static client application 728 and has nothing 
to do with generating modified documents in server formats or small device formats, 
much less with generating one from the other, determining differences between them, or 
merging corresponding changed content, according to the limitations recited in claim 4. 

For at least the reasons above, the rejection of claim 4 is unsupported by the cited 
art and removal thereof is respectfully requested. 

Regarding claim 5, contrary to the Examiner's assertion, Mansour fails to teach or 
suggest generate a modified version of the small device document in the server format 
from the modified version of the small device document in the small device format; and 
compare the modified version of the small device document in the server format to the 
document in the server format. The Examiner cites paragraph [0185] "updated version" 
as disclosing these limitations. However, as discussed above, the "updated version" of 
paragraph [0185] refers to an application data item that may be "pushed" to a client. It 
has nothing to do with a modified version of a document in either a small device format 
or a server format , much less with generating a modified version of a document in server 
format from a modified version of a small device document in small device format or 
with comparing the modified version of the small device document in the server format to 
the (original) document in the server format, as recited in claim 5. 

For at least the reasons above, the rejection of claim 5 is unsupported by the cited 
art and removal thereof is respectfully requested. 

Regarding claim 6, Mansour fails to teach or suggest generate a modified 
document in an interim format from the modified version of the small device document. 
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The Examiner cites Boucher, updated version, [185], as disclosing this limitation. 
Applicants assume the Examiner means to cite Mansour at this location. However, as 
discussed above, the "updated version" of paragraph [0185] refers to an application data 
item that may be "pushed" to a client. It has nothing to do with generating a modified 
version of a document in an interim format from the modified version of the small device 
document, as recited in claim 6. There is no such interim format disclosed in paragraph 
[185] or elsewhere in Mansour. 

Similarly, Mansour also fails to teach or suggest generate a document in the 
interim format from the document in the server format, in paragraph [0118] "server 
versions". As discussed above, paragraph [0118] refers to a static client application 728 
and has nothing to do with generating modified documents in server formats or small 
device formats, much less with generating a document in an interim format from a 
document in a server format, as recited in claim 6. There is no such interim format 
disclosed in paragraph [01 1 8] or elsewhere in Mansour. 

Further regarding claim 6, Mansour fails to teach or suggest determine one or 
more differences between the modified document in the interim format and the document 
in the interim format. The Examiner cites paragraph [0217] "different form" as 
disclosing this limitation. However, as discussed above, the "different form" of 
paragraph [0217] refers different UI form definitions 2418 for use by the client device 
2402. These UI form definitions 2418 are not modified and unmodified documents in an 
interim format. Instead, they are definitions of display formats themselves. Furthermore, 
this citation has nothing to do with determining differences between multiple form 
definitions, much less with determining differences between multiple documents in the 
same interim format , as recited in claim 6. 

Finally, Mansour fails to teach or suggest for each of the determined differences, 
[the server is configured to] merge corresponding changed content of the modified 
document in the interim format with the document in the interim format; and generate the 
modified version of the document in the server format from the document in the interim 
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format. Here, the Examiner cites paragraph [0075] "converted and merged" as disclosing 
these limitations. However, this citation describes that application data is converted on 
the UI server for rendering by the client device in its native UI (unlike a terminal server, 
which uses the server's UI) and then the client device merges the data with the UI 
components to provide an interactive interface. This passage illustrates the fact that 
rather than generating documents with different formats, the server of Mansour maintains 
application data and display formats separately and relies on client devices to merge data 
and formats. Clearly, the Examiner's citation has nothing to do with the server merging 
changed content of a modified document in the interim format with the (original) 
document in the interim format or with generating a modified version of the document in 
the server format from the document in the interim format, as recited in claim 6. 

For at least the reasons above, the rejection of claim 6 is not supported by the 
* 

cited art and removal thereof is respectfully requested. 

Regarding claim 7, contrary to the Examiner's assertion, Mansour fails to teach or 
suggest the server is further configured to resolve differences between the modified 
version of the document in the server format and another modified version of the 
document in the server format to generate a synchronized version of the document in the 
server format . The Examiner again cites paragraph [0185] "updated version" as 
disclosing this limitation. However, as discussed above, the "updated version" of 
paragraph [0185] refers to an application data item that may be "pushed" to a client. 
There is nothing in this citation to describe that such a "push" is used to resolve 
differences between two modified versions of a document in server format in order to 
synchronize them. In fact, paragraph [0185] specifically refers to the server "pushing" 
application data items to update these data items at the client , not to generate a 
synchronized document in the server format (which would be maintained on the server .) 

For at least the reasons above, the rejection of claim 7 is not supported by the 
cited art and removal thereof is respectfully requested. 
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Regarding claim 8, Mansour fails to teach or suggest display the differences 
between the modified version of the document and the other modified version of the 
document. The Examiner cites paragraph [0074] "display in comparison" as disclosing 
this limitation. However, the only reference to a display in this paragraph is as follow, "if 
the user chooses the "Compose New Message" from an Inbox view, the event script 
associated .with that button will be executed by the client device and a "New Message" 
form may be displayed." This clearly has nothing to do with displaying the differences 
between two different modified versions of a document , as recited in claim 8. 

Furthermore, Mansour fails to teach or suggest for each difference, accept user 
input specifying which version is to be used in the synchronized version of the document. 
Here, the Examiner again cites paragraph [0185] "updated version" as disclosing this 
limitation. As discussed at length above, this paragraph describes a server pushing a 
changed application data item to a client. It has nothing to do with synchronizing two 
modified versions of a document . Furthermore, there is nothing in this citation that 
describes accepting user input specifying which version of each difference between two 
modified documents is to be used in the synchronized version of the document, as recited 
in claim 8. 

For at least the reasons above, the rejection of claim 8 is not supported by the 
cited art and removal thereof is respectfully requested. 

Regarding claim 9, Mansour fails to teach or suggest wherein the server 
comprises a set of policies configured for use in resolving differences between versions of 
documents in the server format, wherein, to resolve differences between the modified 
version of the document in the server format and another modified version of the 
document in the server format, the server is further configured to, for each difference: 
determine one of the polices corresponding to the difference; and apply the determined 
policy to the difference to determine which version is to be used in the synchronized 
version of the document. First, the Examiner fails to address the limitation wherein the 
server comprises a set of policies configured for use in resolving differences between 
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versions of documents in the server format Applicants assert that since Mansour fails to 
disclose resolving differences between multiple, modified versions of documents in a 
server format, it also clearly fails to disclose a set of policies to be applied to such 
resolving. 

The Examiner cites paragraph [0185] "updated version" as disclosing, "determine 
one of the policies (i.e., version) corresponding to the difference; and apply the 
determined policy to the difference to determine which version is to be used in the 
synchronized version of the document." As previously noted, Mansour fails to disclose 
resolving differences between two modified versions of a document in the server format 
at all. Applicants also assert that "versions" of application data items, as described in 
paragraph [0185], are clearly not analogous to " policies configured for use in resolving 
differences between versions of documents" as recited in claim 9. Furthermore, there is 
nothing in this citation or elsewhere in Mansour that discloses the server is further 
configured to, for each difference: determine one of the polices corresponding to the 
difference; and apply the determined policy to the difference to determine which version 
is to be used in the synchronized version of the document. 

For at least the reasons above, the rejection of claim 9 is not supported by the 
cited art and removal thereof is respectfully requested. 

Claims 10-32 include limitations similar to those discussed above regarding 
claims 1-9 and were rejected for the same reasons as claims 1-9. Applicants assert that 
the arguments presented above apply with equal force to claims 10-32, as well. 
Therefore, for at least the reasons presented above, the rejection of claims 10-32 is not 
supported by the cited art and removal thereof is respectfully requested. 
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CONCLUSION 



Applicants submit the application is in condition for allowance, and prompt notice 
to that effect is respectfully requested. 

If any extension of time (under 37 C.F.R. § 1.136) is necessary to prevent the 
above-referenced application from becoming abandoned, Applicants hereby petition for 
such an extension. If any fees are due, the Commissioner is authorized to charge said 
fees to Meyertons, Hood, Kivlin, Kowert, & Goetzel, P.C. Deposit Account No. 
501505/5681-10700/RCK. 

Also enclosed herewith are the following items: 
[3 Return Receipt Postcard 
I I Petition for Extension of Time 
O Notice of Change of Address 
□ Other: 



Meyertons, Hood, Kivlin, Kowert, & Goetzel, P.C. 

P.O. Box 398 

Austin, TX 78767-0398 

Phone: (512) 853-8850 

Date: May 15,2006 
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Respectfully submitted, 




Robert C. Kowert 
Reg. No. 39,255 

ATTORNEY FOR APPLIC ANT(S) 



